Kubernetes - 认证与权限

认证

所有 Kubernetes 集群有两类用户：由 Kubernetes 管理的 Service Accounts （服务账户）和（Users Accounts）普通账户。

普通账户是假定被外部或独立服务管理的，由管理员分配 keys，用户像使用 Keystone 或 google 账号一样，被存储在包含 usernames 和 passwords 的 list 的文件里。

需要注意：在 Kubernetes 中不能通过 API 调用将普通用户添加到集群中。

普通帐户是针对（人）用户的，服务账户针对 Pod 进程
普通帐户是全局性。在集群所有 namespaces 中，名称具有惟一性
通常，群集的普通帐户可以与企业数据库同步，新的普通帐户创建需要特殊权限。服务账户创建目的是更轻量化，允许集群用户为特定任务创建服务账户
普通帐户和服务账户的审核注意事项不同
对于复杂系统的配置包，可以包括对该系统的各种组件的服务账户的定义

Service Accounts

Service Account Admission Controller

通过 Admission Controller 插件来实现对 pod 修改，它是 apiserver 的一部分。创建或更新 pod 时会同步进行修改 pod。当插件处于激活状态（在大多数发行版中都默认情况）创建或修改 pod 时，会按以下操作执行：

如果 pod 没有设置 ServiceAccount，则将 ServiceAccount 设置为 default
确保 pod 引用的 ServiceAccount 存在，否则将会拒绝请求
如果 pod 不包含任何 ImagePullSecrets，则将 ServiceAccount 的 ImagePullSecrets 会添加到 pod 中，即将 ImagePullSecrets 的验证交给 ServiceAccount，然后 Pod 只和 ServiceAccount 交互
为包含 API 访问的 Token 的 pod 添加了一个 volume
把 volumeSource 添加到安装在 pod 的每个容器中，挂载在 /var/run/secrets/kubernetes.io/serviceaccount

Token Controller

TokenController 作为 controller-manager 的一部分运行。异步行为:

观察 serviceAccount 的创建，并创建一个相应的 Secret 来允许 API 访问
观察 serviceAccount 的删除，并删除所有相应的 ServiceAccountToken Secret
观察 secret 添加，并确保关联的 ServiceAccount 存在，并在需要时向 secret 中添加一个 Token
观察 secret 删除，并在需要时对应 ServiceAccount 的关联

Service Account Controller

Service Account Controller 在 namespaces 里管理 ServiceAccount，并确保每个有效的 namespaces 中都存在一个名为 default 的 ServiceAccount。

授权（RBAC）

RBAC：基于角色的权限控制。

Role

代表一个角色，会包含一组权限，没有拒绝规则，只是附加允许。它是 Namespace 级别的资源，只能作用与 Namespace 之内。

# 查看已有的角色信息
kubectl get role -n ingress-nginx -o yaml

配置文件：

yml

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  labels:
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx
  name: nginx-ingress
  namespace: ingress-nginx
rules: # 规则
  - apiGroups:
      - ""
    resources: # 权限控制的资源
      - configmaps
      - pods
      - secrets
      - namespaces
    verbs: # 可以执行的权限
      - get
  - apiGroups:
      - ""
    resourceNames:
      - ingress-controller-label-nginx
    resources:
      - configmaps
    verbs:
      - get
      - update
  - apiGroups:
      - ""
    resources:
      - configmaps
    verbs:
      - create

ClusterRole

功能与 Role 一样，区别是 ClusterRole 资源类型为集群类型，而 Role 只在 Namespace。

# 查看某个集群角色的信息
kubectl get clusterrole view -o yaml

RoleBinding

Role 或 ClusterRole 只是用于制定权限集合，具体作用与什么对象上，需要使用 RoleBinding 来进行绑定。

作用于 Namespace 内，可以将 Role 或 ClusterRole 绑定到 User、Group、Service Account 上。

# 查看 rolebinding 信息
kubectl get rolebinding --all-namespaces

# 查看指定 rolebinding 的配置信息
kubectl get rolebinding <role_binding_name> --all-namespaces -o yam

配置文件：

yml

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  # ......
roleRef: # 绑定的角色
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: nginx-ingress-role
subjects: # 绑定的资源主体，一般在 Deployment 配置文件会配置一个 ServiceAccount
  - kind: ServiceAccount
    name: nginx-ingress-serviceaccount
    namespace: ingress-nginx

ClusterRoleBinding

与 RoleBinding 相同，但是作用于集群之上，可以绑定到该集群下的任意 User、Group 或 Service Account。

Kubernetes - 认证与权限 ​

认证 ​

Service Accounts ​

授权（RBAC） ​

Role ​

ClusterRole ​

RoleBinding ​

ClusterRoleBinding ​